fix(cli): sync terminal cursor with input caret for CJK IME - #1142

Good instinct and unusually thorough test coverage (unit tests for calculateMultilineInputCursorPosition covering ASCII, CJK width, tabs, wrapping, scroll, plus renderer-level lifecycle tests for cursor visibility on focus/unmount). That alone puts this above most first-time-contributor PRs.

Concerns before this is portable as-is:

1. syncHardwareCursor in multiline-input.tsx reaches into (textRef.current as any).textBufferView as TextBufferView — an any-cast into what looks like a private/internal OpenTUI renderable field, not part of its declared type surface. If TextBufferView or textBufferView isn't actually an exported/stable API, this will silently break on the next OpenTUI bump, and there's no fallback beyond the null check. Worth confirming this is intended public surface, or exposing it properly upstream.

2. The line-info-change event listener is attached/detached each render via the useEffect dependency array [focused, displayValue, cursorPosition, lineInfo, syncHardwareCursor] — since syncHardwareCursor is recreated whenever renderer changes (stable) but the effect itself re-runs on every keystroke (displayValue/cursorPosition change every input), this re-subscribes the listener on every keystroke. Not necessarily wrong, but worth confirming there's no listener leak/thrash under rapid typing.

3. The author states manual Windows Terminal / CJK IME verification — the actual scenario in CJK IME candidate window anchors to wherever text last changed on screen, not to the input caret — real terminal cursor is never moved #1128 — was not completed. Given this is fixing a rendering/terminal-integration bug that unit tests can only approximate (mocked TextBufferView, no real IME), this is the biggest gap. A porting maintainer will want to confirm the fix against a real terminal before merging.

Recommend keeping the calculation logic (calculateMultilineInputCursorPosition is clean and well-tested) but validating the textBufferView access is safe and doing the manual IME test pass before porting.

Addressed the follow-up feedback in the latest push:

• Centralized the OpenTUI 0.3.4 visual textBufferView.lineInfo access behind a guarded adapter while preserving wrapped-line semantics.
• Separated hardware-cursor synchronization from the line-info-change subscription, so the listener is no longer reattached on ordinary caret/value changes.
• Added a renderer-level wrapped visual-row regression test.
• Focused suite: 81/81 passed; repeated run (--rerun-each 3): 243/243 passed; git diff --check passed.
• Manually verified in Windows Terminal with Microsoft Pinyin across normal CJK input, cursor movement, wrapped lines, and scrolling. The IME candidate window followed the input caret correctly.

No additional scope was added beyond the existing two files.